There are situations in which some of the data values used by a transaction are missing or completely unknown. Missing information is sometimes called null data. The use of null data in a database management system (DBMS) requires extensions to the framework used for predicate evaluation during query execution. In particular, when a predicate is evaluated against a null, the result of the evaluation cannot be true or false. Thus, to allow or support evaluations that involve nulls, one must introduce a value called "maybe" or "unknown" as a truth value, or introduce Boolean nulls. Since predicates can be combined by means of the operators AND, OR and NOT to form arbitrarily complex predicates, rules are needed to specify the results of evaluating complex predicates. This is usually done by means of an appropriate form of algebra. For example, when there are no nulls involved, evaluation of complex predicates is performed according to Boolean algebra. Generally, prior art DBMS's that support null data support only one kind of null data and evaluate complex predicates having one or more null data values using three valued logic.
The present invention was developed, in part, based on the premise that it would be desirable in many applications to have more than one kind of null, where the different types of nulls represent the different reasons why information is missing (e.g., "unknown," "divide by zero," "undefined," "prohibited," and so on). Although it is possible to allow multiple kinds of null data and still use three valued logic, using a three valued logic process to evaluate truth expressions having multiple kinds of null data effectively erases all information about the kinds of null data involved.
Furthermore, in addition to data being missing, there are situations in which data values are not missing, but are also not 100% reliable. For example, when a transaction uses "browse" access to read data, some of the data read by the transaction may be uncommitted data written by active transactions. More specifically, some of the data read by the transaction with browse access may be write locked by other transactions, while other portions of the data read may not be write locked by any other transactions. As a result, some of the data (i.e., the data not write locked by any other transaction) read by the transaction with browse access will be 100% reliable, while some other portions of the data (i.e., the data write locked by other transactions) will be less than 100% reliable.
When a write lock is held by a long lived transaction (LLT), the transaction is likely to have different phases and the values of the data on which write locks are held may have corresponding levels of reliability. Typically, data values for which an LLT hold write locks will be least reliable at the beginning phases of the LLT and more reliable at the later phases of the LLT. The prior art, however, treats all such data uniformly as either unreliable data or null data.
It is a goal of the present invention to provide a more flexible mechanism for evaluating queries that arc functions of data having multiple levels or classifications of unreliability. In particular, it is a goal of the present invention to provide a query evaluation technique that classifies data with respect to its type, degree or classification of unreliability and that maintains and properly combines data unreliability classification information as it evaluates complex query expressions.